home *** CD-ROM | disk | FTP | other *** search
/ OpenGL Superbible (2nd Edition) / OpenGL SuperBible e2.iso / tools / Mesa-3.0 / SRC / MGL / MGLMESA.TXT < prev    next >
Encoding:
Text File  |  1998-06-30  |  5.7 KB  |  126 lines
  1. Things to do:
  2. -------------
  3.  
  4.  . Generic functions for ROP codes using the putPixel functions in the
  5.    MGL so we can handle this properly. It will be slower but it will
  6.    work.
  7.  
  8.  . Optimize internals where we see that there are bottlenecks in the code.
  9.  
  10.    1. First place to start is with the matrix manpipulation code and to
  11.       automatically determine if the matrices are special for special case
  12.       code.
  13.  
  14.    2. The second place is with the transformation of vertices to ensure
  15.       that this is efficient,
  16.  
  17.    3. The third place is to provide the ability to remove all internal
  18.       error checking for maxium performance for calls to Mesa.
  19.  
  20.    4. The fourth place is to optimize the calls to Mesa to directly call
  21.       the loaded API functions rather than calling the C based wrappers
  22.       via our MGL function pointers as this will boost performance.
  23.  
  24.    5. The fifth place is to check how the conversions between floating
  25.       point and integer proceed and to optimize that.
  26.  
  27.    6. The sixth place is to determine what parts of the library can be
  28.       optimized with high performance assembler code. The matrix math
  29.       and vectors transforms is one area as well as conversions between
  30.       floating point and integers.
  31.  
  32.  . Disable all OpenGL support unless we have linear access for speed and
  33.    simplicity reasons.
  34.  
  35.  . Optimize solid scanline fills where the masks as all 1! Mesa should
  36.    really optimize for this at a higher level than this, but then again
  37.    the device drivers would probably handle this better anyway with
  38.    optimized triangle filling code.
  39.  
  40.  . In order to support our z-buffering functions, we need to have our
  41.    code to the zbuffer allocation stuff as we need to own the z-buffer.
  42.    We will only support 16-bits per pixel, and we will share the z-buffer
  43.    between the front and back buffers to conserve memory.
  44.  
  45.  . Add support for the swap hint rectangles extension in Microsoft OpenGL
  46.    so that we can handle dirty rectangles.
  47.  
  48.  . Need to figure out how to properly handle beginDirectAccess and
  49.    endDirectAccess within Mesa so that we can properly arbitrate between
  50.    the accelerator and our code, but we also want to make sure that we
  51.    optimize this to minimize the number of calls to do this. Perhaps
  52.    we need to set up a new device driver function that is optionally
  53.    called before a primitive or set of primitives is rendered to set up
  54.    the direct framebuffer access to get around this problem.
  55.  
  56.    We may be able to do this with the begin/end functions, but we will
  57.    need to enable/disable these functions depending on whether we need to
  58.    do the direct access stuff or not for the rendering function that is
  59.    coming up (ie: depending on the mode specific in the begin call I guess).
  60.  
  61.  . Optimize the cases for different color depths and the write_span type
  62.    functions for direct framebuffer access for maximum speed. We will need to
  63.    figure out the glBegin for direct access stuff, but this will give us a
  64.    big speed improvement for basic rendering functions that we can't accelerate
  65.    using the MGL functions.
  66.  
  67.  . Optimize the cases for glDrawPixels and glReadPixels which will be used
  68.    to implement bitmaps and menus etc. We should be able to pass this through
  69.    to MGL_putBitmap for simple 1:1 cases and MGL_stretchBitmap for non
  70.    1:1 cases that need to be stretched.
  71.  
  72.  . Enable optimized dithering routines for packed pixel TrueColor devices
  73.    using the code from the XMesa implementation. We can use these functions
  74.    with relatively optimized plotting code direct the bitmap surface
  75.    for reasonable speed when doing dithering in HiColor modes.
  76.  
  77.  . Add support for both 16bit and 32bit depth buffering in Mesa. I guess
  78.    currently only one depth buffer format is supported when you compile
  79.    Mesa which is a bit of a problem. We really want to be able to switch
  80.    between the two formats on the fly.
  81.  
  82.    It would be nice to be able to do the same for Accumulation buffers etc,
  83.    but it would get way out of hand handling the different combinations of
  84.    rendering functions internally. Perhaps if we have hardware acceleration
  85.    a 16bit z-buffer is a good choice because of the small memory requirements.
  86.  
  87.    We could cut the MGL down to support only one depth buffer size which would
  88.    simplify a lot of the internal rendering functions.
  89.  
  90. Stuff to be updated in OpenGL/Cosmo support:
  91. --------------------------------------------
  92.  
  93.  . Figure out how to handle the compile time and runtime extensions
  94.    that Mesa provides that the others do not and how to provide the
  95.    commonality between them. We need to use the same mechanism that
  96.    Cosmo/Microsoft OpenGL use to determine the extensions and get the
  97.    function pointers so we can do this dynamically.
  98.  
  99. New extensions in Mesa/OpenGL
  100. -----------------------------
  101.  
  102.  . Transparent 2D glDrawPixels.
  103.  . Dirty rectangles based on Microsoft's extension.
  104.  . SGI's 8bpp texture mapping extensions.
  105.  
  106. Notes:
  107. ------
  108.  
  109.  . Why is the current rendering context pointer passed in to all rendering
  110.    functions when only one context can be the currently active one? Surely
  111.    we should simply use the global variable to avoid passing this around
  112.    and to get faster access to the internal structures?
  113.  
  114.    Answer: to support multi-threading.
  115.  
  116.  . When we read and write pixels, what range does Mesa expect the color
  117.    components to be in in HiColor modes (ie: 555 etc)? Should they be
  118.    normalized to [0->255] or should they be in [0-4] etc.
  119.  
  120.    Currently it is set for [0->4] for writing and reading.
  121.  
  122.  . How are solid 2D rectangles drawn with Mesa accelerated? Are they drawn
  123.    as two triangles or is there an optimized solid rectangle function?
  124.  
  125.  . Is there code in Mesa right now to support 16-bpp TrueColor dithering?
  126.